/ScriptX/Documentation/HTML Files/language guide HTML/ch09_14.gif)
getModule function, described on page 201, to get access to the ModuleClass object itself, supplying the module's name as an interned NameClass object. Here, the ModuleClass object that represents module MyModule is assigned to the global variable theModule:global theModule := getModule @mymodule
Once you have access to a module object, you can add it to a storage container just as you would any other object. This example creates a title container and adds a module to that container:
-- create a title container. theStartDir is the default for dir:
global tc := new TitleContainer path:"test.sx" dir:theStartDir
append tc (getModule @mymodule)
One weakness to this approach is that it builds the title container that is to store module MyModule outside of that module. What if the title container's startup action needs to refer to classes or objects that are defined in the module itself? The following code example demonstrates how to create a module and create the container that stores it within the same module. This example also saves that module to the title container without saving any variables that refer to the creation of the container.
First, create a module, TopModule. In this module, you create any classes and global variables that are to be stored with the module in your title or library container.
module TopModule
uses ScriptX
end
in module TopModule
global topVar1 := "the first topVar"
class TopModuleTitle (TitleContainer)
instance variables
accessoryProtocols:#("string1", "string2", "stringEtc")
end
Suppose you want to avoid having the container itself store variables that refer to the creation of the container-that's wasted space. To make the code that builds a title or library container non-persistent, enclose it in parentheses and make all the "throwaway" variables local.
(
local tc := new TopModuleTitle \
dir:theScriptDir \
path:"modacct.sxt" \
name:"top"
append tc (getModule @TopModule)
tc.startUpAction := ( tc ->
print "here we go"
load tc[1]
print topVar1
)
close tc
)
For more information on adding objects to title containers, library containers, and accessory containers, see the "Title Management" chapter of the ScriptX Components Guide.
Of course, lexical names do not exist at runtime. A ScriptX program is compiled into bytecode. But the objects that those names represent during compilation must still be loaded into memory. Modules provide a convenient mechanism for saving and retrieving code.
Typically, a ScriptX title starts up by loading all modules in which its classes and functions are defined. During compilation, the order in which modules are defined and the order in which source files are compiled generally matters. It is quite possible for a class to be defined in one module, while its methods are defined in another module that uses the first module.
At runtime, the order in which modules are loaded generally does not matter. It is usually easiest to load all class and function objects at start-up. Modules are not useful as a program segmentation technique, since classes and functions, once loaded, cannot be unloaded.
In some cases, saving a module may cause more information to be stored than you want. Consider the following network of modules:
PaintInterface and PaintImplementation. In addition, it includes two clients of the PaintInterface module that use its variables: PaintApplication and DrawInterface.
Assume, for this example, that you wanted to store only the painting functions (PaintInterface and PaintImplementation) into a painting library. If you stored PaintInterface first, the ScriptX object store would include all the other modules that use PaintInterface-all the modules in the network.
Storing PaintImplementation first, rather than PaintInterface, prevents this sort of runaway storage of modules. Because implementation modules, by definition, are never used by any other modules, only the modules that the implementation module itself uses are stored.
Here are some hints for storing only the modules you need:
This document is part of the ScriptX Language Guide, one of the volumes of the ScriptX Technical Reference Series. ScriptX is developed by the ScriptX Engineering Team at Apple Computer, successor to the Kaleida Engineering Team at Kaleida Labs, Inc.